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DETAILED ACTION 

Claim Rejections - 35 USC § 101 

1. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

2. Claims 25, 28-32 are rejected under 35 U.S.C. 101 because the claimed invention is directed 
to non-statutory subject matter. Applicants Specification states that the medium can be a carrier 
wave [Applicants' Specification, page 60, paragraphs 210-211]. Signals and data structures 
are non-statutory subject matter {see MPEP 2106 JV.A.l). Since claims^28-32 also includes this 
non-statutory subject matter, they are rejected for the same reason. Also, according to the 
USPTO Interim Guidelines, claim 25 should recite "encoded with" instead of "carrying." 
Correction is required. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 
102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the 
subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill 
in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 
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Bradshaw et al. in view of Cheng et al. and Bergins et al. 

4. Claims 1,4-5, 8-9, 12-13, 16-17, 20-21, 24, and 33-35 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Bradshaw et al. (USP 6,674,731) in view of Cheng etal. (US? 6,040,851) 
and Bergins et al. (USP 5,826,198). 

5. With regard to claims 1 , 9, and 1 7, Bradshaw et al. discloses the transmission of TCP/IP data over 
a satellite link from a hub station to a plurality of remote terminal units [Abstract]. Bradshaw et al. 
further teaches user terminals [col. 4, lines 58-61] (hosts) connected to remote units [col. 4, lines 65- 
67] (terminal unit). The remote unit contains a receiver [col. 4, lines 14-15] and a transmitter [Fig. 8] 
for two-way communication. Bradshaw et al. also teaches the hub use of DVB format data frames 
[coL 3, lines 47-49]. The receiver must contain a MAC to DVB converter [col. 12, lines 38-40] to 
conform to DVB protocol format that is supported by the hub [col. 3, line 49]. Bradshaw et al. also 
teaches an RF receiver coupled to an antenna to permit exchange of data between the remote terminal 
and the satellite [Fig. 10]. A burst demodulator must be present in the RF receiver for demodulating 
the signal over the satellite link due to the nature of satellite communications. The data frame , 
conforms with the DVB protocol format (i.e., the return channel frame format) [col. 3, line 49]. The 
hub station [Fig. 2, 104] is shown with the antenna and the RF transmitter/receiver. Thus, these 
elements are interpreted as containing the satellite-to-hub interface. Bradshaw et al. further discloses 
that the hub is connected to an external packet switched network [Fig. 2, element 24; col. 4, lines 
25-29], which, in this case, is the internet. The hub must necessarily be able to convert the protocol 
data frames received from the satellite into requests to/from content servers [col. 5, lines 13-17]. 
Bradshaw et al. also teaches a multi-layer protocol interface for the hub-to-terminal interface as the 
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TCP/IP data is encapsulated into a MAC data frame [coi. 7, lines 62-63] and because the TCP/IP 
frames are also formatted within the DVB frame [col. 8, lines 47-51]. 

Bradshaw et al. fails to specifically disclose the transmission of data bursts from the terminal 
to the host via a direct USB connection. Bradshaw et al. discloses that the connection between the 
remote unit I08A (terminal) and the user terminal 1 ISA (host) is a LAN 1 16 [Fig. 2]. Bradshaw et al. 
can use a standardized bus (e.g., the IEEE 802.6 DQDB) for conveying bursty video, which also has 
the advantage of improved performance characteristics [see generally^ col. 3, lines 65-67]. Thus, the 
remote unit I08A (terminal) in Bradshaw et al. receives the wireless signals from satellite 106 and 
transports them to the user terminal 1 1 8 A host via a LAN 116 [Fig. 2]. A LAN involves much more 
complexity in connecting devices, such as the remote unit 108A (terminal), to multiple user terminals 
1 ISA (hosts) [SeeId.Y Furthermore, a remote unit I08A (terminal) requires an interface and a driver 
in order to condition the signal and provide the physical interface to the LAN [col. 14, lines 15-23]. 
LAN 1 16 allows remote unit 108A (terminal) to transport information in multiple formats/standards 
to those multiple user terminals 1 18A (hosts), which are connected to LAN 1 16. It is well known to 
those skilled in the art to use a direct connection between a terminal and host, instead of a LAN, 
because such a connection reduces the complexity of communicating over a LAN and allows more 
direct and efficient communications between the two devices. Moreover, it is also well known to 
those of ordinary skill in the art that there must be a functional interface between a receiver and 
transmitter (or transceiver) such that the transmitter receives data from the functional interface for 
transmission. For example, Bergins et al. (USP 5,826,198) discloses an interface 44 between the 
transmitter 46 and receiver 48 which, along with controller 42, controls the flow of voice information 
such that received information is sent to the speaker 26 and input information (from the microphone 
28) is sent through the transmitter [Fig. 1, col. 4, lines 22-30]. 
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Cheng et al. (USP 6,040,851) discloses a set-top box along with a receiver sub-system that 
integrates network-dependent functions into a digital interface conditional access module (DICAM) 
(host interface) which then can implement bursty video [MPEG 1, 2, or 3, col. 6, line 25] from a 
variety of sources (to include satellite dishes and cable) and then implement them on a personal 
computer (host) to receive the data [Abstract; col. 1, lines 11-33]. Cheng et al. uses the combination 
of a set-top universal box (STUB) (terminal) and the DICAM (host interface) to separate out the 
network-dependent and network-independent streams and functions [Figs. 3-5; col. 2, lines 8-17]. 
Thus, Cheng et al.'s STUB/DICAM [Figs. 3-5] receives satellite input signals [col. 6, line 16] and 
outputs the data/streams via a direct connection such as a universal serial bus (USB) [col. 6, lines 20- 
26]. A USB bus specifically supports (common) bursty video traffic. Bradshaw et al. and Cheng et 
al. both involve the transmission and reception of data over a wireless communication channel [both 
receive satellite signals]. Moreover, both Bradshaw et al. and Cheng et al. disclose integrated 
services, specifically, transmitting the received data to a user terminal [user terminal 11 8A in 
Bradshaw et al. and a PC in Cheng et al.]. Thus, it would have been obvious to one of ordinary skill 
in the art at the time of the invention to have used the received satellite communications of Bradshaw 
et al. with the less-complex and directly-connected USB bus disclosed in Cheng et al. to connect the 
remote unit 108A (terminal) and the user terminal 1 18A (host) because integrated services require 
interoperability between the receipt, and use, of bursty video data transmissions which contribute to 
improved performance characteristics. 

6. With regard to claims 4, 12, and 20, Bradshaw et al. discloses all teaches that MPEG format data 
is packaged into DVB protocol format [col. 2, lines 66-67], and TCP/IP data is encapsulated into an 
Ethernet MAC data frame [col. 7, lines 62-63], that is, multi-layer protocol with support for DVB. 
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7. With regard to claim 5, Bradshaw et al. discloses that the data exchanged over the satellite link is 
TCP/IP [col. 3, lines 37-39]. 

8. With regard to claims 8, 16, and 24, Bradshaw et al. discloses that the packet-switched network 
is the internet [Fig, 2, element 24]. 

9. With regard to claims 13 and 21, Bradshaw et al. discloses IP [coL 7, lines 62-63], an lETF- 
standardized protocol used for interfacing receiver and transmitter units, as well as for transmitting 
data. 

10. With regard to claims 33-35, neither Bradshaw et al. nor Cheng et al. specifically disclose using 
USB super frames to send data bursts to the host. Cheng et al. discloses a USB serial interface, which 
can handle bursty video and uses USB frames. It is well known to those skilled in the art that USB 
super frames can be used by devices sending video data (and other isochronous applications) when 
(a) there are large amounts of data to be sent; and (b) the device can reserve enough time slots to 
send the super frame [wherein problems with USB bus cycles and bandwidth can arise when the 
device has to contend with other devices on the same USB bus]. Since the combination of Bradshaw 
et al. and Cheng et al. teaches the less-complex and directly-connected USB bus between remote unit 
108A (terminal) and user terminal 1 18A (host), as noted above, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to have used USB super frames to' send large 
bursts of video data between remote unit 108A (terminal) and user terminal 1 18A (host) because 
there would be no other device to contend with for the USB bus's cycle or bandwidth. 
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Bradshaw et ai in view of Cheng et al, and Bergins et at. further in view ofBirdwell et al, 

1 1 . Claims 6, 14, and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et 
al. in view of Cheng et al. and Bergins et al. as applied to claims 1, 9, and 17 above, and further in 
view ofBirdwell et al. (US Patent Publication 2001/0024435). 

12. With regard to claims 6, 14, and 22, Bradshaw et al. does not specifically disclose little and big 
endian data formats. However, Birdwell et al. discloses endian formats for IP packets transmitted 
over a satellite link [paragraph 0058]. Bradshaw et al. requires the determination of the beginning, 
the end, the LSB, and/or the MSB of the transmitted data frames in order to process the data frames. 
Endian formats aid in determining whether the first byte in the transmitted frames is the LSB or 
MSB. Thus, it would have been obvious to one of ordinary skill in the art at the time of the invention 
to have used the teachings of Bradshaw et al. in processing of transmitted data frames to have used 
the endian formats to aid in determining the LSB and MSB so that data alignment can be achieved at 
the receiver for either synchronization or CRC calculations. 

Bradshaw et al, in view of Cheng et al. and Bergins et al. further in view of Jorgenson et al. 

13. Claims 7, 15, and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et 
al. in view of Cheng et al. and Bergins et al. as applied to claims 1, 9, and 17 above, and further in 
view of Jorgenson et al. (USP 6,680,922). 
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14. With regard to claims 7, 15, and 23, Bradshaw et al. does not specifically disclose IGD packets. 
However, Jorgenson discloses UDP for transmission of packets over a wireless link [col. 12, lines 
46-48]. IGD packets are formed from UDP packets. Therefore, it is obvious to those of ordinary 
skill in the art that UDP datagrams convey useful information parameters about the wireless link 
including the return channel ID and loading information. Moreover, UDP/IP packets encapsulate 
multiple data types, including IGD packets. 

Bradshaw et al. in view of Cheng et aL and Bergins et al, 

15. Claims 25, 29, and 32 are rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw 
et al. in view of Cheng et al. and Bergins et al. 

16. With regard to claim 25, Bradshaw et al. discloses the transmission of TCP/IP data over a 
satellite link from a hub station to a plurality of remote terminal units [Abstract]. Bradshaw et al. 
further teaches user terminals [coi. 4, lines 58-61] (hosts) connected to remote units [col. 4, lines 65- 
67] (terminal unit). The remote unit contains a receiver [col. 4, lines 14-15] and a transmitter [Fig. 8] 
for two-way communication. Bradshaw et al. also teaches the hub use of DVB format data frames 
[col. 3, lines 47-49]. The receiver must contains a MAC to DVB converter [col. 12, lines 38-40] to 
conform to DVB protocol format that is supported by the hub [col. 3, line 49]. Bradshaw et al. also 
teaches an RF receiver coupled to an antenna to permit exchange of data between the remote terminal 
and the satellite [Fig. 10]. A burst demodulator must be present in the RF receiver for demodulating 
the signal over the satellite link due to the nature of satellite communications. The data frame 
conforms with the DVB protocol format (i.e., the return channel frame format) [col. 3, line 49]. The 
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hub station [Fig. 2, 104] is shown with the antenna and the RF transmitter/receiver. Thus, these 
elements are interpreted as containing the satellite-to-hub interface. Bradshaw et al. further discloses 
that the hub is connected to an external packet switched network [Fig. 2, element 24; col. 4, lines 
25-29], which, in this case, is the internet. The hub must necessarily be able to convert the protocol 
data frames received from the satellite into requests to/from content servers [col. 5, lines 13-17]. 
Bradshaw et al. also teaches a multi-layer protocol interface for the hub-to-terminal interface as the 
TCP/IP data is encapsulated into a MAC data frame [col. 7, lines 62-63] and because the TCP/IP 
frames are also formatted within the DVB frame [col. 8, lines 47-51] 

Bradshaw et al. fails to specifically disclose the transmission of data bursts from the terminal 
to the host via a direct USB connection. Bradshaw et al. discloses that the connection between the 
remote unit I08A (terminal) and the user terminal I ISA (host) is a LAN 1 16 [Fig. 2]. Bradshaw et al. 
can use a standardized bus (e.g., the IEEE 802.6 DQDB) for conveying bursty video, which also has 
the advantage of improved performance characteristics [see generally, col. 3, lines 65-67]. Thus, the 
remote unit I08A (terminal) in Bradshaw et al. receives the wireless signals from satellite 106 and 
transports them to the user terminal II 8A host via a LAN 1 16 [Fig. 2]. A LAN involves much more 
complexity in connecting devices, such as the remote unit 108 A (terminal), to multiple user terminals 
I I8A (hosts) [See Id.], Furthermore, a remote unit I08A (terminal) requires an interface and a driver 
in order to condition the signal and provide the physical interface to the LAN [col. 14, lines 15-23]. 
LAN 116 allows remote unit I08A (terminal) to transport information in multiple formats/standards 
to those multiple user terminals I I8A (hosts), which are connected to LAN 116. It is well known to 
those skilled in the art to use a direct connection between a terminal and host, instead of a LAN, 
because such a connection reduces the complexity of communicating over a LAN and allows more 
direct and efficient communications between the two devices. Moreover, it is also well known to 
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those of ordinary skill in the art that there must be a functional interface between a receiver and 
transmitter (or transceiver) such that the transmitter receives data from the functional interface for 
transmission. For example, Bergins et al. (USP 5,826,198) discloses an interface 44 between the 
transmitter 46 and receiver 48 which, along with controller 42, controls the flow of voice information 
such that received information is sent to the speaker 26 and input information (from the microphone 
28) is sent through the transmitter [Fig, 1, col. 4, lines 22-30]. 

Cheng et al. (USP 6,040,851) discloses a set-top box along with a receiver sub-system that 
integrates network-dependent functions into a digital interface conditional access module (DICAM) 
(host interface) which then can implement bursty video [MPEG 1, 2, or 3, col. 6, line 25] from a 
variety of sources (to include satellite dishes and cable) and then implement them on a personal 
computer (host) to receive the data [Abstract; col. 1, lines 11-33]. Cheng et al. uses the combination 
of a set-top universal box (STUB) (terminal) and the DICAM (host interface) to separate out the 
network-dependent and network-independent streams and functions [Figs. 3-5; col. 2, lines 8-17]. 
Thus, Cheng et al.'s STUB/DICAM [Figs. 3-5] receives satellite input signals [col. 6, line 16] and 
outputs the data/streams via a direct connection such as a universal serial bus (USB) [col. 6, lines 20- 
26]. A USB bus specifically supports (common) bursty video traffic. Bradshaw et al. and Cheng et 
al. both involve the transmission and reception of data over a wireless communication channel [both 
receive satellite signals]. Moreover, both Bradshaw et al. and Cheng et al. disclose integrated 
services, specifically, transmitting the received data to a user terminal [user terminal 1 18A in 
Bradshaw et al. and a PC in Cheng et al.]. Thus, it would have been obvious to one of ordinary skill 
in the art at the time of the invention to have used the received satellite communications of Bradshaw 
et al. with the less-complex and directly-connected USB bus disclosed in Cheng et al. to connect the 
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remote unit 108A (terminal) and the user terminal 1 ISA (host) because integrated services require 
interoperability between the receipt, and use, of bursty video data transmissions which contribute to 
improved performance characteristics. 

17. With regard to claim 29, Bradshaw et al. discloses IP [col, 7, lines 62-63], an lETF-standardized 
protocol used for interfacing receiver and transmitter units, as well as for transmitting data. 

18. With regard to claim 32, Bradshaw et al. discloses that the packet-switched network is the 
internet [Fig. 2, element 24]. 

19. With regard to claim 36, neither Bradshaw et al. nor Cheng et al. specifically disclose using USB 
super frames to send data bursts to the host. Cheng et al. discloses a USB serial interface, which can 
handle bursty video and uses USB frames. It is well known to those skilled in the art that USB super 
frames can be used by devices sending video data (and other isochronous applications) when (a) 
there are large amounts of data to be sent; and (b) the device can reserve enough time slots to send 
the super frame [wherein problems with USB bus cycles and bandwidth can arise when the device 
has to contend with other devices on the same USB bus]. Since the combination of Bradshaw et al. 
and Cheng et al. teaches the less-complex and directly-connected USB bus between remote unit 
108A (terminal) and user terminal 1 18A (host), as noted above, it would have been obvious to one of 
ordinary skill in the art at the time of the invention to have used USB super frames to send large 
bursts of video data between remote unit 108A (terminal) and user terminal 1 18A (host) because 
there would be no other device to contend with for the USB bus's cycle or bandwidth. 
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Bradshaw et al in view of Cheng et al. andBergins et aL, further in view ofBirdwell et al. 

20. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et al., Cheng 
et al., and Bergins et al. as applied to claim 25 above, and further in view ofBirdwell et al. 

21 . With regard to claim 30, Bradshaw et al. does not specifically disclose little and big endian data 
formats. However, Birdwell et al. discloses endian formats for IP packets transmitted over a satellite 
link [paragraph 0058). Bradshaw et al. requires the determination of the beginning, the end, the 
LSB, and/or the MSB of the transmitted data frames in order to process the data frames. Endian 
formats aid in determining whether the first bytes in the transmitted frames are the LSB or MSB. 
Thus, it would have been obvious to one of ordinary skill in the art at the time of the invention to 
have used the teachings of Bradshaw et al. in processing of transmitted data frames to have used the 
endian formats to aid in determining the LSB and MSB so that data alignment can be achieved at the 
receiver for either synchronization or CRC calculations. 



Bradshaw et al, in view of Cheng et al. and Bergins et aL, further in view ofJorgenson et al 

22. Claim 31 is rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et al. in view 
of Cheng et al. and Bergins et al. as applied to claim 25 above, and further in view ofJorgenson et al. 
(USP 6,680,922). 

23. With regard to claim 31, Bradshaw et al. does not specifically disclose IGD packets. However, 
Jorgenson discloses UDP for transmission of packets over a wireless link [col. 12, lines 46-48]. IGD 
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packets are formed from UDP packets. Therefore, it is obvious to those of ordinary skill in the art 
that UDP datagrams convey useful information parameters about the wireless link including the 
return channel ID and loading information. Moreover, UDP/IP packets encapsulate multiple data 
types, including IGD packets. 

. Response to Arguments 

24. Applicant's arguments with respect have been considered but are moot in view of the new 
grounds of rejection. 

Conclusion 

25. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Mark A. Mais whose telephone number is 572-272-3138. The examiner can 
normally be reached on M-Th 5am-4pm. 

26. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, 
Wing F. Chan can be reached on 571-272-7493. The fax phone number for the organization where 
this application or proceeding is assigned is 571-273-8300. 
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27. Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained 
from either Private PAIR or Public PAIR. Status information for unpublished applications is 
available through Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the 
Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information system, call 800- 
786-9199 (IN USA OR CANADA) or 571-272-1000. 

M/lM WING CHAN 

November 30, 2007 SUPERVISORY RftTENT EXAMfNER 




